Section: New Results

Deductive Verification

Synthetic topology in HoTT for probabilistic programming.

F. Faissole and B. Spitters have developed a mathematical formalism based on synthetic topology and homotopy type theory to interpret probabilistic algorithms. They suggest to use proof assistants to prove such programs [91] [92]. They also have formalized synthetic topology in the Coq proof assistant using the HoTT library. It consists of a theory of lower reals, valuations and lower integrals. All the results are constructive. They apply their results to interpret probabilistic programs using a monadic approach [23].

A Toolchain to Produce Correct-by-Construction OCaml Programs

In the context of the research project Vocal, J.-C. Filliâtre, A. Paskevich, and M. Pereira, together with L. Gondelman (postdoc in January 2017) and S. Melo de Sousa (visiting Associate Professor from UBI, Portugal, in Sep/Oct 2017), designed and implemented a toolchain for the verification of OCaml code using Why3 [33]. In this framework, the user provides a formal specification within comments embedded in the OCaml interface file together with an implementation in Why3. Two tools automatically translate the former to a Why3 specification and the latter to an OCaml code. One the refinement proof is completed on the Why3 side, the overall diagram commutes, ensuring the soundness of the OCaml code.

Ghost monitors

M. Clochard, C. Marché, and A. Paskevich designed a new approach to deductive program verification based on auxiliary programs called ghost monitors. This technique is useful when the syntactic structure of the target program is not well suited for verification, for example, when an essentially recursive algorithm is implemented in an iterative fashion. The approach consists in implementing, specifying, and verifying an auxiliary program that monitors the execution of the target program, in such a way that the correctness of the monitor entails the correctness of the target. This technique is also applicable when one wants to establish relational properties between two target programs written in different languages and having different syntactic structure [32] [29].

This approach is based on an earlier variant proposed in M. Clochard's PhD thesis [11]. The ghost monitor maintains the necessary data and invariants to facilitate the proof, it can be implemented and verified in any suitable framework, which does not have to be related to the language of the target programs. M. Clochard introduced one such framework, with an original extension that allows one to specify and prove fine-grained properties about infinite behaviors of target programs. The proof of correctness of this approach relies on a particular flavor of transfinite games. This proof is formalized and verified using the Why3 tool (http://toccata.lri.fr/gallery/hoare_logic_and_games.en.html).

Extracting Why3 programs to C programs.

R. Rieu-Helft, C. Marché, and G. Melquiond devised a simple memory model for representing C-like pointers in the Why3 system. This makes it possible to translate a small fragment of Why3 verified programs into idiomatic C code [26]. This extraction mechanism was used to turn a verified Why3 library of arbitrary-precision integer arithmetic into a C library that can be substituted to part of the GNU Multi-Precision (GMP) library [128].

Verification of highly imperative OCaml programs with Why3

J.-C. Filliâtre, M. Pereira, and S. Melo de Sousa proposed a new methodology for proving highly imperative OCaml programs with Why3. For a given OCaml program, a specific memory model is built and one checks a Why3 program that operates on it. Once the proof is complete, they use Why3's extraction mechanism to translate its programs to OCaml, while replacing the operations on the memory model with the corresponding operations on mutable types of OCaml. This method is evaluated on several examples that manipulate linked lists and mutable graphs [24].

Verification of Parameterized Concurrent Programs on Weak Memory Models

Modern multiprocessors and microprocesseurs implement weak or relaxed memory models, in which the apparent order of memory operation does not follow the sequential consistency (SC) proposed by Leslie Lamport. Any concurrent program running on such architecture and designed with an SC model in mind may exhibit new behaviors during its execution, some of which may potentially be incorrect. For instance, a mutual exclusion algorithm, correct under an interleaving semantics, may no longer guarantee mutual exclusion when implemented on a weaker architecture. Reasoning about the semantics of such programs is a difficult task. Moreover, most concurrent algorithms are designed for an arbitrary number of processes. D. Declerck [12] proposed an approach to ensure the correctness of such concurrent algorithms, regardless of the number of processes involved. It relies on the Model Checking Modulo Theories (MCMT) framework, developed by Ghilardi and Ranise, which allows for the verification of safety properties of parameterized concurrent programs, that is to say, programs involving an arbitrary number of processes. This technology is extended with a theory for reasoning about weak memory models. The result is an extension of the Cubicle model checker called Cubicle-W, which allows the verification of safety properties of parameterized transition systems running under a weak memory model similar to TSO.

Counterexample Generation

S. Dailler and C. Marché worked on extensions and improvements of the counterexample generation feature of Why3, used in particular by the SPARK front-end for Ada [102] [101]. When the logic goal generated for a given verification condition is not shown unsatisfiable by an SMT solvers, some solver can propose a model. By carefully reverting the transformation chain (from an input program through the VC generator and the various translation steps to solvers), this model is turned into a potential counterexample that the user can exploit to analyze why its original code is not proved. The extension consists in a deep analysis of the complete model generated by the solver, so as to extract more information and produce better counterexamples. A journal paper giving the details of the whole process was published [14]

Alias Control for SPARK Program Verification

G.-A. Jaloyan and A. Paskevich, together with C. Dross, M. Maalej, and Y. Moy made a proposal for introduction of pointers to the SPARK language, based on permission-driven static alias analysis method inspired by Rust's borrow-checker and affine types [35]. By ensuring that at any point of execution any writable value can only be accessed through a single name, it is possible to apply the standard rules of Hoare logic (or weakest precondition calculus) to verify programs with pointers. The proposed framework was implemented in the GNAT Ada compiler and the SPARK toolset.